1. Field of the Invention
This invention relates to computers. In particular, the invention relates to a scheduling driver to implement a protocol using time estimates for use with a device that does not generate interrupts.
2. Description of Related Art
Generally, a driver is a program that controls a device. Every device, such as a printer, disk drive, or keyboard, needs to have a driver to be operable with a computer. Many drivers, such as keyboard driver, come with an operating system. For other devices, a driver needs to be loaded when the device is connected to the computer. A driver acts like a translator between the device and the applications that use the device. Each device has its own set of specialized commands that only its driver knows. In contrast, most applications access devices by using generic commands. The driver, therefore, accepts generic commands from an application and translates them into specialized commands for the device.
Most device drivers handle hardware requests using the following sequence of steps:
1. Initiate a hardware request or put it in a queue if the device is already busy.
2. When the device generates an interrupt, the current request has been completed. At this point, return the results of the request to the application and initiate the next request in the queue.
Typically, each application uses a synchronous call to execute its request. The operating system (O/S) returns control to the application when the driver completes the request, which happens when the device generates an interrupt.
However, a problem arises when dealing with slow devices that do not generate interrupts. Unfortunately, most drivers utilized with a device that does not generate an interrupt do not have mechanisms to fairly share access among competing applications to the device and tend to utilize Central Processing Unit (CPU) processing time inefficiently in accommodating the competing applications. For example, some drivers utilized with these types of devices poll device registers to determine I/O completion. Unfortunately, with these types of drivers, the application often pauses or stalls execution to wait for the completion of the Input/Output (I/O) request during device processing, or executes an excessive number of I/O requests, both of which unnecessarily waste CPU processing time.